0.15 status Work has been going swiftly on 0.15, but there are still many major topics we have left to close. We mentioned previously that our estimate for release would be near the end of February, and while this has been our internal goal, we won't quite be able to make it. One of the main reasons for this delay is us underestimating how long it would take to stabilize 0.14 and the new multiplayer code. We thought that because it was a relatively small 'major' release, that it would not take much time to make it stable. However the great community members playing the experimental version kept finding bugs for us to fix, and even now there are still several 0.14 bugs being identified and fixed in 0.15. The extending bug fixing of 0.14 was no doubt necessary, but it has led us to be somewhat behind schedule on several features of 0.15. Our current optimistic estimate is that we will be able to release an experimental version of 0.15 at the end of March, and we will keep you all up to date on its progress.
Hello, long time no talk, we've got some catching up to do... Almost 1 year ago (FFF-365) we said "we don't think that [the expansion] will take less than a year to develop". Well it has been less than a year and it is not finished, so we kept our word on that :). But while it might not be finished, there is a still a lot we have done so far.
Hello, I will start today's Factorio friday facts with a famost quote: Only two things are infinite. The universe and the Factorio map. But i'm unsure about the Factorio map. Albert Einstein.
Good evening Factorians, today we had a presentation about the game at one of the universities here in Prague for the subject called "Video game development". It was focused on what is it like to develop an indie game. So yesterday we spent some time reflecting the past year and a half to come up with topics to talk about. We were thinking a lot about the period about a year ago before the Indiegogo campaign started, when the game was completely unknown to the public and we were close to burning out. The positive finding wat that as opposed to that period the work is now much less stressful and generally enjoyable. Maybe we (and people in general) should think about our down moments more often to better appreciate what we have ... Last Friday Facts promised a stable 0.8 release in the beginning of this week. Well, that was a false promise because couple of more bugs have been found that resulted in the new record for number of bugfix releases. Now we have the 0.8.8 in the experimental stage. If there are no serious issues found this will be made stable during the weekend. Having so many bugfix releases is rather annoying (and we plan to improve here by starting with automated testing) but it doesn't slow us down in the regular development. We have multiple development branches and the work on the 0.9 has been going for a while in the master branch, while the bugfixes are collected in the current release branch (the 0.8.x) and then merged back into the master. Talking about the 0.9, the work has been progressing well. Quite some internal rework of concepts is required for the oil industry and fluids in general. However, yesterday we already had an assembling machine that makes a recipe from some items and water supplied by the pipe. For this to work the recipe mechanism has been generalized and in the end (not yet done) following will be possible: The recipe ingredient can be a fluid. The recipe can have multiple results (both items and fluids). The results of the recipe can be randomized (there will be a probability of getting the result and a min - max range for the amount of the result). There might not be much more fluid content aside from the oil (and its variations) in the 0.9, however the mechanisms will be there for the modders to play with and take advantage of them. And we are curious what they come up with:) Kovarex has been working on the native blueprints for some time and he has the core functionality more or less finished. Of course that is just a small portion of the total work required (polishing, bugfixing, integration with other concepts, etc.) but it is something that can already be played with in the 0.9 branch. And it is actually quite fun to play with. The system is relatively straightforward now: You make the blueprint item. You select what to store in it (you get the blueprint preview on the item afterwards). You place it and the construction robots build it. You can check it out on the mini picture series below, where blueprints have been used to build the standard furnace line. If you would like to share your thoughts or ideas about this post, you can do so on our forum.
Steam Awards (Klonan) Steam has opened up the nominations for this years Steam Awards. Last year Factorio was actually selected as a nominee for the 'Haunts My Dreams' award. There is a category this year for 'Best Developer', and many in the community have wanted to nominate us for that category. Unfortunately to be eligible, we would need to have a developer page set up on Steam. We had some discussions, and decided to wait until we have a final 'Wube Software' logo and theme finalized before setting up a developer page. This means you won't be able to vote for us as best developer this year... This doesn't meant that you can't nominate Factorio for one of the categories, and there has already been some discussion on the subreddit about which games people are voting for.
Cliffs - introduction and gameplay (Twinsen) Several months ago TOGoS (Dan) half-jokingly mentioned that what Factorio really needed was mountains and cliffs. This was also suggested many many many times. Albert immediately got very excited and they started having some discussions about how to make it happen. Fast forward a few months, and Ernestas had made some cliff graphics that looked really nice when layered onto pretty much any type of terrain. Fast forward a few more months and add a few months of programming and polishing, and cliffs are almost done, so we will be showing them to you today. Cliffs, together with the other map changes TOGoS did, should make the map look much more diverse and interesting compared to 0.15. Hopefully it will make exploration more fun, since you will be finding more diverse and unique areas in the world. Since cliffs block your path, they can affect gameplay significantly. To not make this annoying, cliffs are never too long and often have gaps. We tried to balance the length so they will be long enough to create interesting combat situations, or with some modifications serve as a natural wall against the biters, but so long that they block your path when you want to get somewhere. Cliffs will also not appear in the starting area, to give you plenty of space for your initial base. Finally, in Factorio nothing should stand in the way of automation, so if you don't like cliffs, you can always blow them up using a new mid-game item called "Cliff explosives". Cliffs - graphics (Albert) Map generation is hard mainly because it is procedurally generated. That means that the computer is mixing all the pieces to create the terrain on the fly. This leads the artists to a very difficult situation,because it is very hard to guess in which conditions the tilesets will be used. Factorio terrain 0.1 We started the generation of terrain in Factorio with very basic rules, mainly mixing clusters of 32px tiles. But obviously that wasn't enough. Factorio terrain 0.3 With better looking tiles, transitions from one terrain to another, and variations of tiles, terrain looks much better. But this technique was a pain for the artist to generate an interesting and detailed tileset. The 32px grid was killing any attempt to have a natural looking terrain. Factorio terrain 0.12 New technique: Instead of having only variations of 32px tiles, we produce a tileset with different sizes (x32, x64, x128, x256) in order to break this squary sense of grid, and even being able to render more detail in bigger sized tiles. So terrain looks much more natural. The visible tile-grid is almost gone, and we start spreading a new concept for us: the doodads. These are little sprites of plants and rocks randomly spread throughout the map in order to provide more variability and an organic feeling. Factorio terrain 0.15 Things are getting better, the doodads were optimised and we're able to place much more of them, creating more interesting patterns and mixtures. It is also worth it to mention that the introduction of the high resolution graphics does a lot to help the look of the terrain. Factorio terrain 0.16 After all those iterations, the next terrain generation integrates a couple of new concepts: the decals which are "just" doodads but ground-related. Decals are meant to generate terrain accidents and details without being oppressed by the rules of "tileability" and size. Basically decals are patches on top of a tileset that are very rich in detail. In combination with the doodads, the absence of the tile-grid and the high-res, we start to have a natural looking terrain. I have to add that the good and fast work of Ernestas, our environment artist, made possible the evolution of this new state of terrain. Now with our new techniques, the creation of a new tileset is very smooth. Even with all the improvements, terrain still looks too flat, so another addition to 0.16 are the cliffs. Finally we can break the flatness of the Factorio surface, without having to change the mechanics of the game. This new feature can add a bit to the fun of designing a factory by taking advantage of the topology of the map. Or can lead combat to more interesting situations. There are more additions to the terrain, and we will dedicate more time to this subject in future posts.
Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.
Hello, version 0.15.30 was released today, and we consider it to be our first 0.15 stable version candidate, as long as no other big bugs appear, we will have 0.15 stable in a week. As the teasing never ends, it is time to show some ongoing work on 0.16 already.
Hello, it seems the summer heat has finally subsided, and we have not had to run our AC units the whole week. We mentioned earlier we have had Dominik in for a testing week, and we are happy to say that he is quite qualified for a position here, so will be remaining with us. Tom has also joined us, moving here from the Republic of Ireland, and has been getting settled in working through a lot of the small unassigned tasks. It also seems most of us are back from our vacations, so the pace is picking up again. Most of the work this week has been on the unentertaining spectrum, with a lot of internal reworking and refactoring going on. A lot commits related to fixing our compilation after the move to C++17. Many of the GUI and input action functions were broken (such as rebinding keys, switch map editor tabs, setting combinator filters), so its been a team effort to fix these as they are found. Hopefully not many will slip through the cracks and into release.
